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Abstract 

EXPECT  provides  an  environment  for  developing 
knowledge-based  systems  that  allows  end-users  to  add 
new  knowledge  without  needing  to  understand  the 
details  of  system  organization  and  implementation. 
The  key  to  EXPECT's  approach  is  that  it  understands 
the  structure  of  the  knowledge-based  system  being 
built:  how  it  solves  problems  and  what  knowledge  it 
needs  to  support  problem-solving.  EXPECT  uses  this 
information  to  guide  users  in  maintaining  the  knowl¬ 
edge-based  system.  We  have  used  EXPECT  to  develop 
a  tool  for  evaluating  transportation  plans. 

1.  Introduction 

To  successfully  attack  the  large  scale,  real  world  domains 
targeted  by  the  ARP  A/Rome  Labs  Planning  Initiative  col¬ 
laboration  is  required.  People  and  machines  must  work 
together  to  solve  problems,  each  contributing  what  they  do 
best.  In  addition  to  planning  systems,  other  computerized 
tools  are  needed  to  support  that  collaboration — such  as 
tools  for  evaluating  and  critiquing  plans. 

In  this  paper  we  describe  the  EXPECT  knowledge  acqui¬ 
sition  framework  which  we  have  used  to  construct  a  plan 
evaluation  tool,  the  COA  Evaluator.  This  application 
evaluates  alternative  military  transportation  plans  for 
moving  personnel  and  materiel  from  bases  to  crisis  situa¬ 
tions.  It  takes  a  high-level  description  of  a  possible  plan, 
or  course-of-action  (COA),  and  produces  an  evaluation  of 
the  plan  from  a  logistics  perspective.  The  evaluation  indi¬ 
cates,  for  example,  how  many  logistic  personnel  will  be 
required  to  execute  it,  and  how  long  the  plan  will  take  (the 
closure  date).  Using  the  evaluator,  planners  can  decide 
which  COA  looks  most  attractive. 

In  complex,  crisis  planning  domains,  the  knowledge 
based  systems  that  are  developed  to  support  planning  (like 
the  COA  Evaluator)  must  be  adaptable  to  meet  the  par¬ 
ticulars  of  a  given  situation:  no  one  can  envision  all  the 
situations  in  which  these  tools  might  be  used,  or  the 
knowledge  that  would  be  needed  to  support  them.  Because 
these  tools  will  be  used  in  crisis  situations,  we  cannot  rely 
on  a  phalanx  of  experienced  knowledge  engineers  to  per¬ 
form  the  modifications.  Instead,  we  must  empower  end- 


users  so  that  they  will  be  able  to  adapt  the  tools  to  their 
needs. 

EXPECT  is  the  framework  for  knowledge  based  systems 
that  we  are  developing  to  support  knowledge  acquisition 
and  explanation.  A  central  idea  behind  EXPECT  is  the  no¬ 
tion  that  more  powerful  acquisition  and  explanation  tools 
can  be  constructed  if  acquisition  and  explanation  concerns 
are  reflected  in  the  structure  of  the  knowledge  based  sys¬ 
tems  we  create.  That  is,  rather  than  developing  tools  that 
operate  on  conventional  knowledge  based  systems,  it  is 
first  necessary  to  modify  the  architecture  of  the  target 
knowledge  based  systems  so  that  they  will  be  structured  in 
a  way  that  provides  better  support  for  knowledge  acquisi¬ 
tion  and  explanation.  It  is  then  possible  to  build  tools  that 
exploit  this  additional  information  to  provide  enhanced 
capabilities. 

In  prior  work  on  the  EES  framework  [Neches  et  al, 
1985;  Swartout  et  al.,  1991]  we  explored  the  architectural 
modifications  that  are  needed  to  support  explanation. 
EXPECT  extends  the  EES  framework  to  support  knowledge 
acquisition.  In  this  paper,  we  discuss  the  architectural 
features  that  support  knowledge  acquisition. 

There  are  several  knowledge  acquisition  capabilities  that 
we  seek  to  support  with  the  EXPECT  architecture: 

1.  Users  should  be  able  to  modify  both  factual  knowledge 
and  problem  solving  knowledge.  Although  many  acquisi¬ 
tion  systems  provide  good  support  for  modifying  factual 
knowledge,  support  for  modifying  problem  solving  knowl¬ 
edge  is  more  limited.  In  early  acquisition  systems  (such  as 
MORE  [Eshelman  1988],  SALT  [Marcus  and  McDermott 
1989],  and  ROGET  [Bennett  1985]),  a  single  problem 
solving  strategy  (e.g.  heuristic  classification)  was  built  into 
the  tool.  As  a  result,  when  one  selected  a  tool,  one  also 
determined  the  problem-solving  strategy.  However,  many 
realistically-sized  knowledge-based  systems  use  several 
problem  solving  strategies,  so  a  tool  that  only  supports  a 
single  strategy  won’t  be  much  help.  Additionally,  if  the 
user  changes  his  mind  about  which  problem-solving  strat¬ 
egy  is  appropriate,  he  may  also  have  to  change  tools,  po¬ 
tentially  losing  a  lot  of  work  in  re-configuring  the  domain 
knowledge.  Recent  knowledge  acquisition  work  [Klinker 
et  al.  1991;  Musen  and  Tu  1993]  has  partially  addressed 
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these  problems  by  creating  tools  that  can  use  multiple 
problem-solving  methods.  In  PROTEGE  II  [Musen  and 
Tu,  1993],  problem  solving  methods  are  composed  of  pre¬ 
encoded  building  blocks.  PROTEGE  II  permits  modifica¬ 
tions  to  problem  solving  by  substituting  one  building  block 
for  another,  however,  users  cannot  modify  the  building 
blocks  themselves.  By  constraining  the  user’s  options  to 
just  those  that  have  been  pre-encoded,  he  may  not  be  able 
to  make  the  modification  he  wants. 

2.  Internal  models  (based  on  the  knowledge  based  system 
being  modified)  should  guide  knowledge  acquisition  rather 
than  external  ones  (based  on  the  acquisition  tool).  Current 
acquisition  systems  cannot  allow  much  modification  to 
problem  solving  knowledge  because  they  use  external 
models  of  problem  solving  that  are  built  into  the  acquisi¬ 
tion  tool.  By  understanding  what  factual  knowledge  is 
needed  to  support  problem  solving  the  acquisition  tool  can 
form  expectations  about  what  additional  knowledge  is  re¬ 
quired  when  the  user  adds  or  modifies  the  system’s  knowl¬ 
edge  base.  In  early  acquisition  tools,  these  expectations 
were  built,  by  hand,  into  the  tool  itself.  In  more  recent 
work,  such  as  PROTEGE  II,  the  interdependencies  be¬ 
tween  factual  knowledge  and  problem  solving  building 
blocks  are  represented,  but  they  are  still  entered  by  hand. 

These  limitations  could  be  overcome  and  a  wider  range 
of  modifications  and  problem  solving  methods  could  be 
supported  if  we  could  use  an  internal  model  for  acquisi¬ 
tion,  that  is,  if  the  expectations  for  acquisition  could  be 
derived  from  the  system  itself.  Eurthermore,  because  the 
interdependencies  would  be  derived  from  the  system  rather 
than  entered  by  hand,  they  would  change  as  the  system 
changed,  and  would  be  more  likely  to  be  correct  and  con¬ 
sistent. 

3.  KA  tools  should  support  modifications  at  a  semantic  (or 
knowledge)  level  rather  than  just  at  a  syntactic  level.  KA 
tools  should  help  ensure  that  the  knowledge  a  user  adds 
makes  sense,  that  is,  that  it  is  coherent  and  consistent  with 
the  rest  of  the  knowledge  base — not  just  that  it  is  syntacti¬ 
cally  correct.  In  addition,  we  want  to  facilitate  the  addition 
of  new  knowledge  by  reducing  the  distance  between  what 
the  user  understands  and  way  the  system  represents  it.  The 
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Figure  1 .  EXPECT  Architecture 


system  must  be  able  to  represent  and  manipulate  concep¬ 
tual  entities  that  are  meaningful  to  users  and  that  are  used 
to  describe  the  domain.  To  further  facilitate  acquisition,  a 
KA  tool  should  allow  users  to  make  modifications  locally, 
and  guide  them  in  resolving  the  global  implications  of  the 
changes.  Providing  assistance  at  the  conceptual  level  and 
allowing  greater  flexibility  in  the  use  of  terminology  will 
free  users  to  focus  on  what  matters:  getting  the  knowledge 
right. 

This  paper  describes  several  features  of  EXPECT’ S  ar¬ 
chitecture  that  directly  support  the  acquisition  goals  we 
outlined  above.  Most  of  the  examples  in  this  paper  are 
based  on  the  COA  evaluator,  but  some  are  from  another 
domain  we  have  used  which  is  concerned  with  the  diagno¬ 
sis  of  faults  in  local  area  networks. 

2.  EXPECT  Architecture  Overview 

A  diagram  of  the  overall  EXPECT  architecture  appears  in 
Figure  1 .  As  we  describe  in  the  next  section,  EXPECT  pro¬ 
vides  explicit  and  separate  representations  for  different 
kinds  of  knowledge  that  go  into  a  knowledge  based  system. 
EXPECT  distinguishes  domain  facts,  domain  terminology 
and  problem  solving  knowledge.  These  different  sources 
of  knowledge  are  integrated  together  by  a  program  instan- 
tiator  to  produce  a  domain-specific  knowledge  based  sys¬ 
tem.  While  the  domain-specific  system  is  being  created, 
the  program  instantiator  also  creates  a  design  history.  The 
design  history  records  the  interdependencies  among  the 
different  kinds  of  knowledge,  such  as  what  factual  infor¬ 
mation  is  used  by  the  problem  solving  methods.  This  in¬ 
formation  is  used  by  the  knowledge  acquisition  routines  to 
form  the  expectations  that  guide  the  knowledge  acquisition 
process. 

3.  Representing  Knowledge  in  EXPECT 

EXPECT  represents  different  types  of  knowledge  separately 
and  explicitly.  After  describing  the  kinds  of  knowledge 
that  are  represented  in  EXPECT  we  present  in  detail  our 
approach  to  representing  goals.  This  explicit  representa¬ 
tion  of  goals  provides  EXPECT  with  a  better  understanding 
of  the  problem  solving  process. 

3.1  Separation  of  Knowledge 

It  is  well  established  that  a  major  source  of  difficulties  in 
understanding,  modifying  and  augmenting  first  generation 
knowledge  based  systems  stemmed  from  the  use  of  low- 
level  knowledge  representations  that  failed  to  distinguish 
different  kinds  of  knowledge  (see  [Chandrasekaran  and 
Mittal,  1982;  Clancey,  1983b;  Swartout,  1983]).  In  a  first 
generation  system,  domain  facts,  problem  solving  knowl¬ 
edge,  and  terminological  definitions  were  all  expressed  in 
rules.  A  single  rule  might  mix  together  clauses  concerned 
with  the  user  interface,  the  system’s  problem  solving  strat¬ 
egy  and  internal  record-keeping.  Because  none  of  these 
different  concerns  were  distinguished,  it  was  often  difficult 
to  understand  exactly  what  the  rule  was  supposed  to  do, 
and  when  modifying  a  rule,  it  was  difficult  to  see  what  the 


effect  of  the  modification  might  be.  Although  early  cri¬ 
tiques  of  these  representations  focused  on  their  failure  to 
provide  good  explanations,  these  architectural  flaws  create 
problems  for  acquisition  as  well. 

A  number  of  second  generation  expert  system  frame¬ 
works  have  emerged  in  recent  years  (see  [Chandrasekaran, 
1986;  Clancey,  1983a;  Hasling  et  ah,  1984;  Neches  et  al, 
1985;  Swartout,  1983;  Swartout  et  al.,  1991;  Wielinga  and 
Breuker,  1986]).  A  common  theme  among  these  frame¬ 
works  is  that  they  encourage  a  more  abstract  representation 
of  domain  knowledge  and  problem  solving  knowledge  that 
makes  distinctions  between  different  kinds  of  knowledge 
explicit. 

By  moving  toward  architectures  that  allow  a  system 
builder  to  distinguish  different  kinds  of  knowledge  and 
represent  them  separately  and  more  abstractly,  second  gen¬ 
eration  frameworks  increased  the  modularity  of  an  expert 
system.  This  modularity  facilitates  KA  by  making  systems 
easier  to  understand  and  augment. 

In  EXPECT,  we  distinguish  three  different  kinds  of 
knowledge:  domain  facts ,  domain  terminology ,  and  prob¬ 
lem  solving  knowledge.  Domain  facts  are  the  relevant  facts 
about  a  system’s  domain.  For  example,  the  domain  facts  in 
a  system  for  transportation  planning  might  include  the  fact 
that  the  naval  port  of  Los  Angeles  is  Long  Beach  and  that 
the  maximum  depth  of  Long  Beach  berths  is  50  feet. 

The  domain  terminology  (or  ontology)  provides  the  con¬ 
ceptual  structures  that  are  used  to  describe  a  domain.  In  a 
transportation  planning  domain,  the  domain  terminology 
would  include  concepts  for  various  kinds  of  ports,  such  as 
airports  and  seaports,  and  concepts  for  describing  the  vari¬ 
ous  kinds  of  movements'  and  materiel  to  be  moved,  among 
other  things.  Concepts  can  be  defined  in  terms  of  other 
concepts.  Domain  terminology  provides  a  set  of  terms,  or 
concepts,  that  can  be  used  to  describe  some  situation.  The 
existence  of  a  concept  does  not  imply  that  the  object  it  de¬ 
scribes  actually  exists — concepts  are  just  descriptions  that 
may  or  may  not  apply  in  any  given  situation.  Domain 
facts,  on  the  other  hand,  use  domain  terminology  to  repre¬ 
sent  what  exists. 

To  represent  both  domain  facts  and  terminology, 
EXPECT  uses  Loom  [MacGregor  1988].  Loom  provides  a 
descriptive  logic  representation  language  and  a  classifier 
for  inference.  Facts  are  represented  as  Loom  instances, 
while  terminology  is  represented  using  Loom  concepts. 
Both  instances  and  concepts  are  structured,  frame-based 
representations  with  slots  that  indicate  relations  in  which 
the  object  is  involved. 

Loom’s  classifier  benefits  knowledge  acquisition.  Given 
a  set  of  defined  concepts,  the  classifier  can  automatically 
organize  them  into  an  is-a  (or  subsumption)  hierarchy  by 
analyzing  their  definitions.  For  example,  suppose  we  de¬ 
fine  the  following  two  concepts: 

an  AIRLIFT-MOVEMENT  is  a  kind  of  MOVEMENT  whose 
destination  is  an  AIRPORT 


'in  transportation  planning,  a  “movement”  specifies  what  is  to  be  moved 
from  an  origin  to  a  destination  at  a  particular  time  using  some  set  of  veh  i- 
cles. 


an  EXPRESS-MOVEMENT  is  a  kind  of  MOVEMENT  whose 
duration  is  less  than  one  DAY  and  whose  desti¬ 
nation  is  an  AIRPORT 

The  classifier  would  figure  out  that  an  express- 
movement  is  also  a  kind  of  airlift-movement,  since  the 
definitions  above  state  that  any  movement  whose  destina¬ 
tion  is  an  airport  is  an  airlift-movement,  and  express- 
movement  meets  that  criteria. 

Loom  provides  a  declarative  foundation  for  representing 
concepts,  relations  and  facts.  The  classifier  helps  maintain 
the  organization  of  the  knowledge  base,  and  as  we  will 
describe,  we  use  it  to  match  problem  solving  methods  with 
goals.  However,  to  be  able  to  analyze  the  interdependen¬ 
cies  between  the  conceptual  structure  of  a  system  and  its 
problem  solving  methods  we  need  a  highly  declarative  rep¬ 
resentation  for  problem  solving  knowledge  as  well.  The 
next  section  describes  our  representation  of  problem  solv¬ 
ing  knowledge. 

3.2  Capturing  Intent  in  Problem  Solving 

Problem  solving  knowledge  in  EXPECT  is  represented  as 
strategies  (called  methods)  for  achieving  particular  goals. 
Each  method  has  a  capability  description  associated  with 
it,  which  states  what  the  method  can  do  (e.g.  “evaluate  a 
COA”),  and  a  method  body  that  describes  how  to  achieve 
the  advertised  capability  of  the  method.  The  steps  can  post 
further  subgoals  for  the  system  to  achieve.  The  language 
used  in  the  method  bodies  allows  sequences  of  steps  and 
conditional  expressions. 

One  of  EXPECT’ s  architectural  features  that  helps  users 
make  modifications  to  problem  solving  knowledge  is  a  rich 
representation  for  goals  and  method  capabilities  that  pro¬ 
vides  an  explicit  representation  of  intent.  This  representa¬ 
tion  makes  it  easier  for  people  to  understand  what  a  method 
is  supposed  to  be  doing,  and  makes  it  easier  for  EXPECT  to 
analyze  a  system’ s  structure  and  hence  provide  guidance  to 
a  user  in  making  modifications. 

In  most  programming  languages,  function  names  have 
no  real  semantics  associated  with  them.  A  good  program¬ 
mer  may  indicate  what  a  function  is  supposed  to  do  by 
giving  it  an  appropriate  name  (e.g.  dear-screen)  but 
as  far  as  the  system  is  concerned,  the  name  is  just  a  string 
of  characters.  Furthermore,  the  relationship  between  the 
function  name  (what  is  to  be  done)  and  the  functional  pa¬ 
rameters  (the  things  that  will  be  involved  in  doing  it)  is 
completely  implicit.  Al  systems  such  as  planners  provide  a 
more  explicit  representation  of  what  is  to  be  done.  Usually 
the  goal  is  represented  as  some  sort  of  state  expressed  in 
some  form  of  predicate  logic.  A  problem  with  this  repre¬ 
sentation  that  affects  both  acquisition  and  explanation  is 
that  it  is  removed  from  the  way  people  think  and  talk  about 
what  they  are  doing,  since  protocols  of  people  solving 
problems  show  that  they  use  verb  clauses  to  describe  what 
they  are  doing  rather  than  state  descriptions  (see  for  exam¬ 
ple,  [Anzai  and  Simon  1979]). 

To  address  these  difficulties  and  decrease  the  distance 
between  EXPECT’ S  internal  representation  and  how  people 
talk  about  what  they  do,  EXPECT’ s  representation  is  based 


on  a  vocabulary  of  verbs.  In  EXPECT,  we  represent  both 
goals  (what  is  to  be  done)  and  method  capability  descrip¬ 
tions  (what  a  method  can  do)  using  a  verb  clause  represen¬ 
tation  based  on  case  grammar.  Each  verb  clause  consists  of 
a  verb  and  a  set  of  slots  (or  “cases”)  that  are  the  parame¬ 
ters.  Eor  example,  the  goal  of  evaluating  a  particular  COA 
is  represented  as  a  verb  clause  where  the  main  verb  is 
“evaluate”  and  its  (direct)  object  slot  is  filled  by  the  COA 
instance  (e.g.,  “coa-3”)  as  follows: 

(evaluate  (obj  (instance  coa-3) ) ) 

The  capability  descriptions  associated  with  methods  are 
represented  similarly,  except  that  they  may  contain  vari¬ 
ables.  Eor  example,  the  following  capability  description 
would  be  associated  with  a  method  that  has  the  capability 
to  evaluate  a  course  of  action  for  force  deployment: 

(evaluate  (obj  (?c  is  (instance-of 
deployment-coa) ) ) ) 

where: 

deployment-coa  is  a  coa 
that  has  force-movements 

Eor  matching,  the  goals  and  capability  descriptions  are 
translated  into  corresponding  Loom  concepts.  The  goal 
above  would  match  this  capability  description  if  coa-3 
had  movements  of  forces,  since  coa-3  would  then  be  a 
kind  of  deployment-coa. 

This  approach  gives  us  a  rich  representation  for  what  is 
intended  by  a  goal  and  what  the  capabilities  of  a  method 
are.  Unlike  the  state-based  representation,  goals  and  capa¬ 
bilities  can  be  easily  paraphrased  into  natural  language. 

Eigure  2  shows  a  simple  method  from  our  system  for 
evaluating  transportation  plans.  It  finds  the  unloading  time 
of  a  movement  by  calculating  the  unloading  time  of  the  set 
of  available  vehicles  of  the  COA  movement.  There  are  two 
things  to  notice  about  this  method.  Eirst,  it  is  relatively 
straightforward  to  paraphrase  the  representations  of  the 
capability  description  and  the  method  body  into  under¬ 
standable  natural  language,  because  their  structure  mirrors 
natural  language.  Second,  this  method  illustrates  the  use  of 
two  general  kinds  of  parameters  that  can  be  passed  in 
EXPECT.  They  distinguish  between  the  kind  of  data  that 
will  be  provided  to  the  method  and  the  kind  of  task  to  be 
accomplished  by  the  method.  They  are  indicated  by  in¬ 
stance-of  or  specialization-of  in  the  capability  de¬ 
scription.  These  keywords  indicate  how  the  matcher  should 
match  these  slots  against  the  corresponding  slots  in  goals. 

Instance-of  indicates  that  the  slot  is  a  data  parameter 
and  will  match  an  instance  of  the  indicated  type.  Thus, 
(instance-of  movement)  will  match  a  movement  in¬ 
stance  or  an  instance  that  is  more  specialized,  instance- 
of  slots  work  much  like  function  parameters  in  conven¬ 
tional  programming  languages:  they  supply  the  data  that 
the  function  manipulates.  However,  in  EXPECT,  slots  on 
goals  do  more  than  just  provide  data;  they  can  also  further 
specify  the  task  to  be  done.  Task  parameters  are  indicated 
by  specialization-of  slots  and  match  against  concepts 
that  appear  in  corresponding  slots  in  the  goal.  Eor  example, 
(specialization-of  unloading-time)  willmatchun- 


capability: 

(find 

(obj  (?t  is  (specialization-of 
unloading-time) ) ) 

(of  (?m  is  (instance-of 

movement) ) ) ) 

result-type :  (instance-of  time-value) 
method:  (calculate 
(obj  ?t) 

(of  (available-vehicles  ?m)  ) ) 

Eigure  2.  A  method  to  calculate  the  unloading  time  of  a 
movement 

loading-time  or  any  of  its  specializations.  The  capa¬ 
bility  description  of  the  method  in  Eigure  2  will  match  a 
goal  such  as: 

(find  (obj  (specialization-of  unloading-time) ) 
(of  (instance  movement-23) ) ) 

or  it  will  match  the  goal: 

(find  (obj  (specialization-of 

emergency-unloading-time) ) 

(of  (instance  movement-23) ) ) 

Notice  the  “obj”  slot  in  both  cases  does  not  supply  data 
but  instead  it  specifies  the  sort  of  information  that  is  sup¬ 
posed  to  be  found  by  the  method.  Specialization-of 
slots  add  an  additional  dimension  for  method  abstraction, 
allowing  us  to  re-use  the  same  method  in  several  different 
contexts,  and  they  are  one  of  the  ways  we  achieve  “loose¬ 
coupling”  in  EXPECT,  which  we  will  discuss  in  detail  in 
Section  4.2.  In  the  example  in  Eigure  2,  ?t  is  bound  to  the 
concept  in  the  goal  that  matches  (specialization-of 
unloading-time) .  The  variable  ?t  is  then  used  in  the 
method  body  to  pass  the  goal  context  on  to  subgoals  so  that 
the  method  body  will  compute  for  example  the  emer- 
gency-unloading-time  rather  than  the  unloading-time 
if  emergency  time  was  specified  in  the  original  goal. 

The  key  features  of  our  goal  representation  are:  1)  it  is 
structured,  2)  a  richer  representation  for  intent  is  provided 
because  the  structure  is  based  on  a  verb  clause  representa¬ 
tion,  and  3)  in  addition  to  data  parameters,  task  parameters 
are  explicitly  distinguished. 

4.  Bringing  Knowledge  Back  Together:  Loose 
Coupling  in  Expect 

We  have  argued  that  by  separating  different  kinds  of 
knowledge  and  providing  explicit  representations  for  them 
knowledge  based  systems  created  within  the  EXPECT 
framework  can  be  easier  to  understand,  and  because  the 
separation  provides  increased  modularity,  they  are  easier  to 
augment  and  modify.  In  this  section,  we  describe  how  the 
program  instantiator  works  to  match  up  and  integrate  dif¬ 
ferent  knowledge  sources.  We  refer  to  the  matching  proc¬ 
ess  we  use  as  semantic  match  because  resources  are 
matched  up  based  on  their  meaning  as  opposed  to  their 
syntax.  We  argue  that  this  loosens  the  coupling  between 
knowledge  sources,  which  can  have  distinct  advantages  for 
knowledge  re-use  and  acquisition. 


4.1  Resolving  Goals:  Semantic  Matching  And  Goal 
Reformulation 

In  many  systems,  matching  of  goals  and  methods  is  done 
on  a  fairly  syntactic  basis.  Lexemes  in  goals  must  match 
those  in  methods,  and  variables  are  matched  by  position. 
In  EXPECT,  we  have  tried  to  move  toward  a  matching 
process  that  is  based  on  the  semantics  of  the  goals  rather 
than  their  syntax,  and  one  in  which  reformulation  can  be 
used  to  achieve  a  match  when  a  more  direct  match  is  not 
possible.  In  EXPECT,  the  ability  to  provide  looser  coupling 
between  goals  and  method  capabilities  depends  on  the  way 
that  they  are  represented.  As  we  described  in  Section  3.2, 
both  goals  and  method  capabilities  are  represented  as  verb 
clauses.  A  main  verb  states  what  is  to  be  done,  using  a 
number  of  slots  that  act  as  “cases”  (as  in  case  grammar). 
Eor  matching,  both  goals  and  method  capabilities  are 
translated  into  Loom  concepts  that  mirror  their  structure. 

Semantic  Match.  One  of  the  mechanisms  EXPECT  pro¬ 
vides  to  achieve  looser  coupling  is  based  on  Loom’s  classi¬ 
fier.  Given  an  existing  hierarchy  of  Loom  concepts  (and 
their  definitions)  organized  according  to  the  subsumption 
(is-a)  relations  between  them,  the  classifier  is  capable  of 
figuring  out  where  in  the  hierarchy  a  new  concept  belongs, 
based  solely  on  the  definitions  of  the  concepts.  To  find 
possible  methods  for  accomplishing  a  goal,  the  Loom  clas¬ 
sifier  is  used  to  find  those  methods  whose  capability  de¬ 
scriptions  subsume  the  goal.  The  classifier  provides  a  form 
of  semantic  match,  because  match  is  based  on  the  meaning 
of  concepts,  not  on  their  syntactic  form. 

The  semantic  matcher  finds  methods  whose  capabilities 
subsume  the  posted  goal  not  only  when  it  is  given  the  class 
name  but  also  when  it  is  given  a  description  of  the  type  of 
object  that  needs  to  be  matched.  An  example  of  this  kind  of 
matching  occurs  in  our  network  diagnosis  domain. 
EXPECT’ s  terminological  knowledge  contains  the  defini¬ 
tion; 

lanbridge-23  is  a  COMPONENT 

that  is  CONNECTED-TO  2  networks 

CONNECTED-COMPONENT  is  a  COMPONENT 

that  is  CONNECTED-TO  some  NETWORK 

When  EXPECT  is  reasoning  with  its  problem  solving 
knowledge  about  how  to  achieve  the  goal: 

(diagnose  (obj 

(instance  lanbridge-23) ) ) 

it  will  be  able  to  match  that  goal  with  a  method  with  the 
capability  description: 

(diagnose  (obj  (?c  is  (instance-of 

CONNECTED-COMPONENT) ) ) ) 

because  the  classifier  can  figure  out  that  lanbridge-23  is 
a  kind  of  component  which  is  connected  to  a  network, 
based  on  the  definitions  of  lanbridge-23  and  connected- 
component  above.  This  kind  of  subsumption  matching 
allows  EXPECT  to  reason  about  the  semantics  of  a  goal  in 
terms  of  the  meaning  of  its  parameters. 


Reformulations.  The  second  mechanism  that  EXPECT 
provides  for  looser  coupling  of  goals  and  methods  is  re¬ 
formulation.  Usually  if  a  method  cannot  be  found  to 
achieve  a  goal  using  semantic  match,  the  system  will  at¬ 
tempt  to  reformulate  the  goal  and  then  look  for  methods  to 
achieve  the  resulting  goal(s).  Goal  reformulation  involves 
decomposing  a  goal  and  then  assembling  a  new  goal  (or 
goals)  by  transforming  pieces  of  the  original  goal  based  on 
their  meaning.  To  be  able  to  perform  goal  reformulation, 
one  needs  an  explicit,  decomposable  representation  for  the 
goal,  definitions  for  the  terms  the  goal  is  constructed  from, 
and  domain  facts  to  drive  the  reformulation  process. 

In  EXPECT,  we  provide  two  general  types  of  reformul  a- 
tions,  conjunctive  and  disjunctive.  A  conjunctive  reformu¬ 
lation  involves  transforming  some  goal  into  a  set  of  goals, 
where  each  of  the  goals  in  the  set  must  be  performed  to 
achieve  the  intent  of  the  initial  goal.  Thus,  a  conjunctive 
reformulation  is  a  form  of  divide-and-conquer:  it  splits  a 
problem  up  into  subpieces  that  together  achieve  the  origi¬ 
nal  goal.  As  in  divide-and-conquer,  the  system  must  find  a 
way  of  recombining  the  results  of  each  of  the  subproblems 
back  into  an  appropriate  result  for  the  original  goal  for  a 
conjunctive  reformulation  to  be  successful.  A  disjunctive 
reformulation  may  also  reformulate  an  initial  goal  into  se  v- 
eral  goals,  but  at  runtime,  only  one  of  the  goals  needs  to 
be  executed  to  achieve  the  intent  of  the  original  goal. 

EXPECT  provides  three  types  of  conjunctive  reformula¬ 
tions:  covering,  individualization,  and  set  reformulations. 

A  covering  reformulation  occurs  when  a  goal  can  be 
transformed  into  several  new  goals  that  together  “cover” 
the  intent  of  the  initial  goal.  Suppose  that  the  following 
goal  is  posted  to  estimate  how  many  support  personnel  are 
required  for  a  COA: 

(estimate  (obj  (specification-of 

support -personnel) 

(for  (instance-of  coa) ) ) 

Using  subsumption  matching,  the  system  would  try  to  find 
methods  for  achieving  this  goal.  Suppose  none  were 
found,  because  the  system  had  no  general  method  for  esti¬ 
mating  the  support  personnel  needed  for  a  COA.  Suppose, 
however,  that  the  system  did  have  methods  for  estimating 
particular  types  of  support  personnel  needed  for  a  COA. 
How  could  these  methods  be  found?  When  the  system 
failed  initially  to  find  a  method,  it  would  then  try  to  refor¬ 
mulate  the  goal  into  new  goals.  If  the  domain  model  con¬ 
tained  the  fact: 

support-personnel  is  partitioned  by 
airport-support-personnel  and 
seaport-support-personnel 

the  system  could  reformulate  the  original  goal  into  two 
new  goals: 

(estimate  (obj  (specification-of 

airport-support -personnel) 

(for  (instance-of  coa) ) ) 

and 


(estimate  (obj  (specification-of 

seaport-support-personnel) 

(for  (instance-of  coa) ) ) 

The  system  would  then  be  able  to  find  the  two  methods  for 
estimating  particular  types  of  support  personnel  needed  for 
a  COA.  For  conjunctive  reformulations,  part  of  the  refor¬ 
mulation  process  involves  finding  a  function  for  re¬ 
combining  the  results  of  each  of  the  reformulations  to  form 
the  result  for  the  original  goal.  The  appropriate  function 
for  combining  results  is  determined  by  the  type  of  the  goal. 
In  this  example,  the  system  adds  the  estimates  together. 

This  sort  of  reformulation  process  reduces  the  need  for 
different  parts  of  the  knowledge  base  to  match  up  exactly, 
which  enhances  the  possibilities  for  knowledge  re-use 
across  systems.  Also,  because  the  system  explicitly  reasons 
through  the  reformulation  process,  more  of  the  design  can 
be  captured  to  support  knowledge  acquisition.  In  this  case, 
if  the  user  added  a  new  type  of  support  personnel  to  the 
knowledge  base,  for  example  unloading-support- 
personnel,  then  the  system  would  use  its  record  of  this 
reformulation  to  determine  that  it  would  be  necessary  to 
perform  the  reformulation  over  again  to  capture  the  new 
type  of  support  personnel.  EXPECT  could  detect  that  the 
user  needs  to  provide  a  method  for  estimating  the  law  en¬ 
forcement  personnel  needed  for  a  COA.  This  is  an  example 
of  how  EXPECT’ s  representations  are  useful  to  guide  KA. 
Individualization  reformulations  are  similar  to  covering 
reformulations,  except  that  they  decompose  a  goal  over  a 
set  of  objects  into  a  set  of  goals  over  individual  objects 
(i.e.,  instances).  Eor  example,  given  the  goal  of  calculating 
the  employment  personnel  of  the  force  modules  in  a  COA: 

(calculate  (obj  (specification-of 

employment-personnel) ) 

(of  (force-modules  coa-2) ) ) 

and  the  domain  fact  that: 

force-modules  of  coa-2  are  the 

instances:  3rd-ACR  57th-IMF  CVN71-ACN 

the  system  could  transform  the  original  goal  into  three 
goals: 

(calculate  (obj  (specification-of 

employment-personnel) ) 

(of  (instance  3rd-ACR) ) ) 

(calculate  (obj  (specification-of 

employment-personnel) ) 

(of  (instance  57th-IMF) ) ) 

(calculate  (obj  (specification-of 

employment-personnel) ) 

(of  (instance  CVN71-ACN) ) ) 

where  each  of  these  goals  corresponds  to  one  of  the  in¬ 
stances  force  modules  of  coa-2. 

Individualization  reformulations  are  used  when  the  set  of 
objects  denoted  by  a  concept  is  known  at  program  instan¬ 
tiation  time.  Sometimes,  however,  it  may  be  known  that  a 
set  of  objects  will  be  passed  to  a  method,  but  the  elements 
of  that  set  may  not  be  known  at  program  instantiation  time, 
that  is,  they  may  only  be  known  later,  at  runtime.  To  deal 


with  that  situation,  EXPECT  provides  a  third  kind  of  con¬ 
junctive  reformulation,  the  set  reformulation.  When  no 
method  is  found  to  achieve  a  goal  that  has  a  set  of  objects 
in  its  parameters,  EXPECT  tries  to  solve  the  goal,  at  run¬ 
time,  for  each  element  of  the  set  in  turn.  Eor  example,  sup¬ 
pose  that  the  following  goal  is  posted  to  calculate  the  clo¬ 
sure  date  2  for  several  movements: 

(calculate 

(obj  (specification-of  closure-date) ) 

(of  (set-of  (instance-of  movement) ) ) ) 

and  there  are  no  methods  that  operate  on  a  set  of  move¬ 
ments.  EXPECT  reformulates  this  goal  over  a  set  into  a 
goal  over  an  individual  movement: 

(calculate 

(obj  (specification-of  closure-date) ) 

(of  (instance-of  movement) ) ) 

The  matcher  will  return  the  method  for  calculating  the 
closure  date  of  a  movement.  At  execution  time,  the  system 
will  loop  over  each  of  the  movements  in  the  set  and  calcu¬ 
late  one  by  one  the  closure  date  of  the  movements  that  are 
included  in  the  set. 

Einally,  EXPECT  provides  the  input  reformulation, 
which  is  a  form  of  disjunctive  reformulation.  It  occurs 
when  no  method  can  be  found  to  handle  one  of  the  inputs 
to  a  goal,  but  several  methods  can  be  found  that  together 
will  cover  the  range  of  possible  inputs  that  will  occur  at 
runtime.  Eor  example,  given  the  goal: 

(calculate 

(obj  (specification-of  closure-date) ) 

(of  (instance-of  movement) ) ) 

suppose  that  the  method  library  contained  no  method  for 
calculating  the  closure  date  of  a  movement  in  general,  but 
there  were  methods  for  calculating  the  closure  date  of  par¬ 
ticular  types  of  movements  and  there  was  a  domain  fact 
that  told  the  system  that: 

movement  is  partitioned  by  airlift-movement  and 
sealift-movement 

then  the  system  could  create  the  goals: 

(calculate 

(obj  (specification-of  closure-date) ) 

(of  (instance-of  airlift-movement) ) ) 

(calculate 

(obj  (specification-of  closure-date) ) 

(of  (instance-of  sealift-movement) ) ) 

The  system  would  expand  methods  for  each  of  these  goals, 
and  then  create  dispatching  code  that  would  select  which 
method  to  use  at  runtime,  based  on  the  type  of  the  instance 
of  movement  that  was  actually  passed  in.  Note  that  unlike 
a  covering  reformulation,  only  one  of  the  branches  of  a 
disjunctive  reformulation  needs  to  be  executed. 

In  summary,  the  loose  coupling  that  EXPECT  provides 
through  semantic  match  and  reformulations  is  crucial  to 
our  approach  to  knowledge  acquisition.  Eirst,  by  moving 
away  from  syntactic  matching,  users  can  add  knowledge  to 


^he  closure  date  is  the  date  when  all  the  material  to  be  shipped  has  ar¬ 
rived  at  the  destination. 


a  system  without  being  as  concerned  with  issues  of  form. 
This  opens  up  the  possibility  for  greater  knowledge  re-use. 
The  second  benefit  is  that  by  having  the  program  instan- 
tiator  reason  extensively  about  the  process  of  matching  up 
goals  and  methods,  more  of  the  design  of  the  knowledge 
based  system  and  the  interdependencies  between  parts  of 
the  system  can  be  captured  (and  hence,  used  to  form  ex¬ 
pectations  for  knowledge  acquisition).  In  reformulating 
goals,  the  program  instantiator  develops  a  rationale  for  how 
a  high-level  goal  can  be  achieved  in  terms  of  lower  level 
goals.  This  sort  of  processing  is  often  exactly  the  sort  of 
reasoning  that  one  wants  to  use  as  a  basis  for  knowledge 
acquisition. 

4.2  The  Program  Instantiator: 

Capturing  Interdependencies 

The  EXPECT  program  instantiator  creates  a  knowledge 
based  system  in  a  refinement  driven  fashion.  Initially,  the 
program  instantiator  starts  with  a  high  level  goal  that  speci¬ 
fies  what  the  knowledge  based  system  is  supposed  to  do. 
For  example,  to  create  a  system  for  evaluating  a  particular 
COA,  the  instantiator  would  be  given  the  following  goal; 
(evaluate  (obj  (instance-of  deployment-coa) ) ) 
This  high  level  goal  determines  the  scope  of  the  knowledge 
based  system  that  EXPECT  will  create.  The  goal  above 
would  create  a  knowledge  based  system  that  could  evaluate 
a  deployment-COA — but  nothing  else.  On  the  other  hand, 
a  goal  such  as: 

(evaluate  (obj  (instance-of  coa) ) ) 

would  create  a  knowledge  based  system  that  could  evaluate 
any  COA  that  was  in  EXPECT’ s  knowledge  base  (assuming 
appropriate  problem  solving  knowledge  was  also 
available).  Thus,  a  single  EXPECT  knowledge  base  can  be 
used  to  create  a  variety  of  knowledge  based  systems,  each 
scoped  to  cover  a  different  (or  poss  ibly  overlapping)  set  of 
problems. 

References  to  instances  that  appear  in  goals  during  the 
program  instantiation  phase  act  as  “place  holders”  for  the 
actual  data  object  that  will  appear  when  the  program  is 
executed.  The  use  of  a  more  general  or  abstract  instance 
results  in  the  creation  of  a  system  that  can  handle  a  wide 
range  of  inputs,  i.e.,  all  the  instances  of  that  type. 

When  a  goal  is  posted,  the  program  instantiator  searches 
its  problem  solving  knowledge  to  find  a  method  whose 
capability  description  matches  the  goal.  This  matching  of 
goals  and  methods  is  a  critical  step  in  the  program  instan¬ 
tiator’ s  reasoning  and  was  the  main  topic  of  the  previous 
section.  How  it  is  done,  and  the  representations  that  are 
used,  have  a  direct  effect  on  how  maintainable  and  reusable 
the  knowledge  base  will  be  and  EXPECT’ s  ability  to  ac¬ 
quire  new  knowledge. 

Once  a  method  is  selected  to  achieve  the  posted  goal,  the 
variables  in  the  method’s  capability  description  are  bound 
to  corresponding  instances  and  concepts  in  the  goal.  The 
body  of  the  method  is  expanded  by  plugging  in  the  bind¬ 
ings  for  the  variables  in  the  body  and  then  posting  its  sub¬ 
goals.  During  this  process,  if  any  of  the  slots  of  an  instance 


are  accessed  by  the  method,  those  accesses  are  recorded  in 
the  design  history.  This  record  of  the  interdependencies 
between  factual  knowledge  (instances)  and  problem  solv¬ 
ing  knowledge  is  later  used  to  form  the  expectations  that 
guide  knowledge  acquisition.  For  example,  if  the  program 
instantiator  notes  that  it  uses  a  method  that  requires  infor¬ 
mation  about  the  berths  of  a  port,  then  when  a  new  port  is 
entered,  the  knowledge  acquisition  routines  will  know  that 
information  about  the  berths  of  that  new  port  needs  to  be 
added. 

A  key  advantage  for  knowledge  acquisition  of  EX- 
PECT’s  approach  is  that  the  program  instantiator  explores 
all  the  possible  execution  paths  through  the  knowledge 
based  systems  it  creates.  It  thus  captures  all  the  interde¬ 
pendencies  between  factual  and  problem  solving  knowl¬ 
edge,  something  which  is  not  possible  to  do  by  analyzing 
execution  traces,  for  example,  since  each  analysis  will  only 
cover  one  execution  path  through  the  system. 

Figure  3  shows  a  partial  view  of  how  the  program  in¬ 
stantiator  expands  goals.  The  top-level  goal  given  to  the 
system  is  to  evaluate  a  deployment  course  of  action.  This  is 
the  goal  posted  in  node  nl.  The  matcher  finds  a  method 
whose  capability  can  achieve  this  goal,  and  the  method's 
capability,  the  bindings,  and  the  method's  body  are  re¬ 
corded  in  the  node.  After  the  bindings  are  substituted  in 
the  method  body,  the  subgoal  of  evaluating  the  transporta¬ 
tion  factors  of  the  COA  would  arise,  and  successive  goal 
expansions  would  produce  the  goals  in  nodes  n2  and  n6. 

Notice  that  even  though  the  method  used  to  achieve  the 
goal  in  nl  can  be  used  for  any  kind  of  COA,  the  bindings 
specify  that  is  used  for  deployment  COAs  and  the  system 
propagates  this  more  specific  type  as  it  expands  the  sub¬ 
goals.  When  no  method  is  found  to  match  a  goal,  EXPECT 
tries  to  reformulate  the  goal  and  try  matching  again.  For 
example,  the  goal  in  node  n2  is  achieved  by  a  covering 
reformulation  of  the  object  parameter  of  the  goal. 

During  the  process  of  expanding  the  goals,  the  program 
instantiator  also  keeps  track  of  the  interdependencies  be¬ 
tween  the  different  components  of  the  knowledge  bases. 
Let  us  look  more  closely  at  node  n6  in  Figure  3.  The  goal 
of  calculating  the  closure  date  of  a  deployment  COA  is 
achieved  with  a  method  whose  body  indicates  that  the  sys¬ 
tem  must  calculate  the  closure  date  of  all  the  movements  of 
the  COA.  Since  movements  is  a  slot  (or  role  in  Loom 
terminology)  of  the  concept  COA,  the  system  annotates  that 
COA  movements  are  used  by  the  method  in  this  node.  The 
factual  domain  knowledge  is  effectively  being  linked  to  the 
problem-solving  knowledge  that  uses  it.  This  is  shown 
with  thick  gray  lines  in  the  figure.  Furthermore,  the  bind¬ 
ings  in  the  node  indicate  that  movements  are  used  (and  thus 
needed)  for  deployment  COAs,  but  not  for  other  types  of 
COAs. 

5.  Flexible  Knowledge  Acquisition 

By  representing  separately  and  explicitly  knowledge  of 
different  types,  EXPECT  allows  users  to  make  changes  to 
the  knowledge  bases  in  terms  that  are  meaningful  in  the 
domain.  By  deriving  the  interdependencies  between  the 


different  types  of  knowledge  as  they  are  used  for  problem 
solving,  EXPECT  can  provide  guidance  for  knowledge  ac¬ 
quisition  that  is  dynamically  generated  from  the  current 
content  of  the  knowledge  bases.  By  representing  explicitly 
problem-solving  methods,  EXPECT  can  reason  about  their 
components  and  support  users  in  modifying  any  compo¬ 
nent  of  the  methods.  This  section  describes  briefly  how 
EXPECT's  KA  tool  takes  advantage  of  the  features  de¬ 
scribed  in  this  paper,  see  [Gil,  1994;  Gil  and  Paris,  1994] 
for  more  details. 

Guiding  Acquisition  of  Domain  Facts 


problem-solving  as  indicated  by  the  interdependencies 
captured  by  the  program  instantiator.  Let  us  go  back  to  the 
example  in  Eigure  3.  Suppose  a  user  wants  to  define  an 
instance  of  a  new  COA.  EXPECT  examines  the  interde¬ 
pendencies  derived  by  the  Program  Instantiator  and  real¬ 
izes  that  only  deployment  CO  As  are  evaluated  (according 
to  the  top-level  goal  in  node  nl).  Other  kinds  of  COAs 
(such  as  employment  COAs)  are  not  evaluated.  Using  that 
information,  EXPECT  will  first  request  the  user  to  be  more 
specific  about  the  COA.  To  provide  maximum  support  to 
the  user  in  providing  this  information,  EXPECT  generates  a 
menu  of  options  that  correspond  to  the  different  kinds  of 


EXPECT's  knowledge  acquisition  tool  supports  users  in  COAs  that  are  known  to  the  system.  The  system  continues 
entering  factual  domain  knowledge  by  automatically  gen-  request  the  user  to  be  more  specific  for  as  long  as  the 

erating  a  dialogue  that  requires  the  information  needed  for  subtypes  of  the  currently  specified  type  are  used  differently 

by  the  system. 

Next,  EXPECT  examines  the  inter¬ 
dependencies  to  request  additional 
information  needed  about  a  deploy¬ 
ment  for  problem  solving.  It  notices 
that  the  roles  used  in  the  methods  are 
force-modules  and  movements.  Ac¬ 
cording  to  the  knowledge  that  is  cur¬ 
rently  available  to  the  system,  the 
JSCP  (Joint  Strategic  Capabilities 
Plan)  information  is  not  used  for 
COA  evaluation.  (JSCP  information 
specifies  high  level  directives  that  are 
irrelevant  for  COA  evaluation.) 
Thus,  EXPECT  requests  the  user  to 
enter  the  force  modules  and  move¬ 
ments  of  the  COA  and  makes  the 
JSCP  information  optional.  Again,  to 
support  the  user,  EXPECT  generates  a 
menu  with  the  force  modules  and 
movements  that  are  currently  defined 
in  the  system  as  suggestions.  If  the 
user  adds  a  step  to  a  problem-solving 
method  that  uses  the  JSCP  of  a  COA, 
EXPECT  will  automatically  detect 
this  new  interdependency  and  ask  the 
user  to  provide  this  information  for 
any  COAs. 

Acquisition  of  Problem-Solving 
Knowledge 

Suppose  now  that  the  domain  knowl¬ 
edge  changed  and  a  new  subclass  of 
support  personnel  was  added,  e.g., 
unloading-support-personnel. 
EXPECT  would  detect  that  to  esti¬ 
mate  the  support  personnel  for  a 
COA  in  node  n2  it  would  generate 
three  subgoals  in  the  covering  refor¬ 
mulation  instead  of  two,  and  thus 


goal:  (evaluate  (obj  (inst-of  deployment-coa) ) ) 
achieved-by:  (evaluate  (obj  (?c  is  (inst-of  coa) ) ) ) 
bindings:  ((?c  (inst-of  deployment-coa))) 
method:  (evaluate  (obj  transportation-factors) 

(of  ?c) ) 


goal:  (estimate  (obj  (spec-of  support-personnel)) 
(for  (inst-of  deployment-coa))) 
achieved-by:  covering-reformulation  obj 


goal:  (estimate  (obj  (spec-of  airport-support-personnel)) 
(for  (inst-of  deployment-coa) ) ) 
achieved-by:  (estimate  (obj  ?asp  is  (... 


goal:  (estimate  (obj  (spec-of  seaport-support -personnel) ) 
(for  (inst-of  deployment-coa))) 
achieved-by:  (estimate  (obj  ?ssp  is  (... 


goal:  (calculate  (obj  (spec-of  employment-personnel) ) 

(of  (inst-of  deployment-coa))) 
achieved-by:  (calculate  (obj  (?p  is  (spec-of 

employment-personnel) ) 
(of  (?c  is  (inst-of  coa))) 
bindings:  ((?p  (spec-of  employment  personnel)) 

(?c  (inst-of  deployment-coa))) 
method:  (add  (obj  (personnel  (force-modules  ?c)  )  ) 


DOMAIN-SPECIFIC  KBS 


DESIGN  HISTORY 


n6  goal:  (calculate  (obj  (spec-of  closure-date)) 

(of  (inst-of  deployment-coa) ) ) 

achieved-by:  (calculate  (obj  (?d  is  (spec-of  closure-date))) 
(of  (?c  is  (inst-of  coa)))) 
bindings:  ((?d  is  (spec-of  closure-date)) 

(?c  (inst-of  deployment-coa))) 
method:  (calculate  (obj  ?d) 
fc  (of  (movements  ?c) ) ) 


■ 

■\r^^ 


PROBLEM  SOLVING  METHODS 


capability:  (calculate 

(obj  (?d  is  (spec-of  closure-date)))* 
(of  (?c  is  (inst-of  coa)))) 
result-type:  (inst-of  time-value) 
method:  (calculate  (obj  ?d) 

(of  (movements  ?c))) 


capab:  (calculate  (obj  (?d  is  (spec-of  employment-personnel))) 
(of  (?c  is  (inst-of  coa)))) 
re suit -type :  (inst-of  person-count) 
method:  (add  (obj  (personnel  (force-modules  ?c) ) ) 


Figure  3.  During  problem  solving,  the  program  instantiator  integrates  the  different  types  of 
knowledge  that  the  diffferent  knowledge  bases  contain  and  keeps  track  of  how  they  are  used  (use  of 


problem  solving  methods  is  in  dark  grey,  use  of  aspects  of  domain  entities  is  in  light  grey).  These  needs  a  problem-solving  method  for 


interdependencies,  dynamically  generated  by  EXPECT  based  on  the  current  available  knowledge,  are  estimating  the  unloaciing-support- 
the  basis  for  guiding  knowledge  acquisition.  personnel  needed  for  a  COA. 


EXPECT  guides  the  user  in  specifying  the  new  method  by 
reusing  one  of  the  other  two  as  a  rough  initial  version  for 
the  new  method  that  the  user  can  correct  by  changing  any 
of  its  components. 

In  addition  to  adding  new  problem-solving  methods, 
EXPECT's  knowledge  acquisition  tool  supports  users  in 
modifying  existing  methods.  Eor  example,  a  user  may  add 
a  new  step  in  a  method  to  use  the  priority  of  a  movement  in 
a  COA  to  decide  whether  or  not  to  use  more  resources  for 
transportation.  Suppose  that  the  priority  of  a  movement  is 
not  defined,  and  that  priorities  are  defined  as  relations  that 
only  apply  to  mission  objectives.  Based  on  this  domain 
knowledge,  EXPECT  notifies  the  user  that  the  priority  of  a 
movement  is  not  defined  and  thus  cannot  be  used  by  a 
method.  EXPECT  also  presents  to  the  user  with  a  menu  of 
all  the  roles  that  are  defined  for  movements  as  options  to 
be  used  in  the  method.  The  knowledge  acquisition  dialogue 
is  updated  if  the  underlying  interdependencies  change.  In 
this  case,  if  the  definition  of  the  role  "priority"  is  changed 
so  that  it  is  defined  for  a  COA  then  the  system  would  allow 
the  user  to  use  the  priority  of  a  COA. 

Summary 

In  real  world  situations,  users  need  to  be  able  to  adapt  their 
tools:  no  one  has  the  foresight  to  envision  all  the  knowl¬ 
edge  a  system  might  need.  Our  research  on  EXPECT  ad¬ 
dresses  that  problem.  By  separating  the  different  kinds  of 
knowledge  that  go  into  a  knowledge  based  system  and 
automatically  deriving  the  interdependencies  between  them 
EXPECT  guides  a  user  in  modifying  a  knowledge  based 
system. 
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